公司的王牌業務總監，正意氣風發地報告他即將簽下一個能改變公司年度業績的指標性大客戶。所有高階主管都面帶微笑，會議室裡充滿了樂觀的氛圍。

「不過，」業務總監話鋒一轉「對方在簽約前，提出了一個小小的要求。他們是家大企業，希望我們能支援『單一登入 (SSO)』，讓他們上千名員工，可以直接用公司內部的帳號密碼登入我們的系統，這樣對他們的資安和管理都比較方便。」他轉頭看向你，臉上帶著的熱情微笑。

公司的 CEO 也立刻看向你，用一種充滿期待、不容拒絕的語氣問道：「SSO 整合，這應該是現在企業軟體的標準功能吧？聽起來很基本，應該很簡單吧？我們一個禮拜，能不能先做個版本給客戶看，展現我們的誠意？」

那一刻，所有人的目光都聚焦在你身上。你感覺自己像是被推上投手丘，被迫在兩人出局滿壘滿球數的情況下，必須只能投出一顆致勝球。你不想讓 CEO 失望，更不想澆熄業務總監的士氣，於是，你幾乎沒有思考，就憑著直覺回答：「沒問題！一個禮拜應該夠！」

會議在皆大歡喜的氛圍中結束。然而，當你拿著這個「一週的承諾」走回座位時，技術主管坐在椅子上緩緩地滑到你身後，用一種異常平靜的語氣對著你說：

「聽說剛剛你跟 CEO 承諾一週啊？那我跟你對一下細節喔，你說的『SSO 整合』…」

「…是指 SAML 還是 OAuth 2.0？客戶那邊的 IdP 是哪一家？Azure AD？Okta？還是其他間？那規格文件拿到了嗎？」
「…使用者第一次登入時，帳號要自動建立嗎？那權限要怎麼對應？他們那邊的『經理』，對應到我們系統的『管理員』還是『進階使用者』？」
「…登出時的流程呢？要支援單點登出嗎？」
「…客戶那邊的資安部門有要求嗎？所有的登入、操作紀錄都要加密保存多久？」

死定了，這是你現在腦海中唯一浮上來的一句話。

聽著技術主管有如連珠砲般的提問，裡面還參雜著許多你過去完全沒聽過的名詞，看著那一行當時看似簡單的需求，腦中已經開始浮現一張錯綜複雜的大型蜘蛛網，你彷彿被那張網緊緊纏住無法呼吸。你在會議上所承諾的一週，看來光是與廠商來回確認細部的條件都無法完成，甚至可能連跟客戶的 IT 部門敲定第一次會議的時間都有困難。

症狀診斷

這個病症，我會稱為「表面複雜度低估症」。

病根在於，我們常常把一個「功能集合 Epic 」，誤判為一個「單一任務 Task 」。

• 功能集合： 就像一座冰山。你看到的「SSO 整合」，只是浮在水面上的那一小角。
• 單一任務： 則是構成這座冰山的每一塊具體的冰塊，例如：「設定 SAML 的憑證交換」、「開發使用者權限對應的邏輯」、「撰寫整合失敗的錯誤提示文案」等等。

你的工作不是去害怕那些看不見的細節，而是用一套專業的方法將它們全部現形，摸清冰山在水面下那巨大且致命的部分。

處方籤

這份處方，是你在面對任何看似簡單的需求時，都必須拿出來的「手術刀組」。

總共提供四把不同的「手術刀」，教你如何從不同角度優雅地分解需求，讓你更容易摸清楚一個需求在實際開發實作上的影響範圍有多大。

第一把刀：使用者旅程拆解法

這是最常用、也最以使用者為中心的切法。忘掉技術，先專注於使用者為了完成他的目標，會經歷哪些主要步驟。

適用時機

任何有清晰使用者流程的功能，例如：購物、註冊、上傳檔案。

手術步驟

1. 定義起點與終點： 使用者從哪裡開始？他最終想達成的目標是什麼？
2. 列出關鍵步驟： 在起點和終點之間，使用者會經過哪幾個關鍵的「動詞」步驟？
3. 拆解每個步驟： 針對每個步驟，再往下思考需要哪些具體的「名詞」元件或任務。

第二把刀：正向與反向流程拆解法

這把刀專門用來挖掘那些隱藏在美好想像之下的魔鬼。大多數的時程延誤，都來自於我們只考慮了「順利」的情況。

適用時機

任何涉及使用者輸入、系統驗證或外部依賴的環節。

手術步驟

1. 定義正向路徑 Happy Path： 假設使用者是個天才，網路永遠不會斷線，所有操作都完美無誤，他會如何順利地完成任務？
2. 腦力激盪反向路徑 Unhappy Paths： 現在開始當個悲觀主義者。很多人不知道該如何思考反向路徑，這裡提供四個常見的「切入角度」，幫助你找出所有潛在的魔鬼：

• 角度一：使用者輸入錯誤
  • 思考：如果使用者是個天兵，他會怎麼亂填？
  • 提問清單：
    • 輸入的格式不對（Email 沒加 @、手機號碼有英文字）怎麼辦？
    • 輸入的內容長度太長或太短怎麼辦？
    • 輸入了系統不支援的特殊符號或 emoji 怎麼辦？
    • 使用者直接複製貼上一長串文字（可能帶有隱藏格式）怎麼辦？
    • 必填欄位沒填就送出怎麼辦？
• 角度二：系統邏輯錯誤
  • 思考：系統的規則可能會如何被違反？
  • 提問清單：
    • 輸入的 Email 帳號已經被註冊過了怎麼辦？
    • 使用者連續輸入錯誤密碼三次，帳號是否該鎖定？
    • 被鎖定的帳號，要如何解鎖？
    • 使用者在兩個瀏覽器同時操作，會不會產生資料衝突？
    • 使用者的權限在操作過程中突然被改變了怎麼辦？
• 角度三：外部依賴錯誤
  • 思考：我們依賴的第三方服務如果掛了怎麼辦？
  • 提問清單：
    • 第三方 API 突然沒回應 Timeout 或回傳錯誤訊息，頁面該如何提示？
    • 第三方 API 回傳的資料格式跟預期不符怎麼辦？
    • 第三方服務的 API 版本突然升級了，我們的系統會壞掉嗎？
• 角度四：環境與網路錯誤
  • 思考：如果使用者的環境很糟，會發生什麼事？
  • 提問清單：
    • 使用者在點擊送出後，手機網路突然斷線了，資料會遺失嗎？
    • 頁面是否需要有載入中 的狀態，防止使用者因不耐煩而重複點擊？
    • 使用者用的是過時的瀏覽器（例如 IE 11），畫面會跑版嗎？
    • 使用者的裝置螢幕尺寸非常小或非常大，排版會亂掉嗎？

第三把刀：角色權限拆解法

這把刀專門用來處理那些「不同人看，長得不一樣」的功能。

適用時機

涉及不同使用者權限的系統，例如：後台管理系統、有不同會員等級的網站。

手術步驟

1. 列出所有「角色」：
   這個功能會有哪些使用者？有哪些不同身份的人會與這個系統互動？
   • 範例（部落格後台）：超級管理員、網站編輯、一般作者、訪客。
2. 定義所有「關鍵動作」：
   每個角色能看到什麼？能做什麼？思考在這個功能裡，有哪些最核心的「動詞」？
   • 範例：查看文章、新增文章、編輯文章、刪除文章、查看數據。
3. 繪製權限矩陣圖/表格：
   畫一個表格，將「角色」作為列，將「動作」作為欄，然後依照實際的權限要求，將每個欄位逐一填上 ✅ 允許或 ❌ 不允許

第四把刀：跨功能依賴拆解法

這把刀最容易被新手 PM 忽略，卻往往是專案延誤的致命元兇。這把手術刀就是專門用來挖掘那些「功能之外」的隱藏工作。

適用時機

所有專案！特別是需要「非開發團隊」支援的專案。

手術步驟

1. 列出所有「外部支援單位」：
   你的專案需要哪些其他部門的火力支援或是會影響到他們使用運作？法務？資安？維運？行銷？客服？
2. 以每個單位的視角，重新審視你的功能：
   • 法務可能會問： 這個功能是否涉及用戶數據？隱私權條款需要更新嗎？
   • 資安可能會問： 有沒有潛在的漏洞？密碼儲存方式安全嗎？
   • 維運可能會問： 這個功能會不會增加伺服器負載？需要設定新的監控警報嗎？
   • 行銷可能會問： 功能上線後，需要我們配合發送 EDM 通知用戶嗎？文案和素材準備好了嗎？
   • 客服可能會問： 我們需要為這個新功能準備 FAQ 嗎？客服後台需要新增對應的查詢工具嗎？
   • 業務可能會問： 這個功能對銷售有幫助嗎？我們需要準備給客戶看的 Demo 材料嗎？

臨床實戰

好，現在你已經拿到了四把鋒利的手術刀。讓我們回到開頭那個讓你胃痛的場景，示範如何用這套工具，將「SSO 整合」這頭看似溫馴、實則龐大的猛獸，進行一次專業的解剖。

第一刀：使用者旅程拆解法

我們先畫出一個企業員工第一次透過 SSO 登入的旅程地圖：

• 點擊「使用企業帳號登入」按鈕 ➜ 被重新導向至客戶的登入頁面 ➜ 輸入企業帳號密碼 ➜ 授權資料存取 ➜ 被重新導向回我們的系統 ➜ 系統自動建立新帳號 ➜ 成功登入並看到產品主頁。

第二刀：正向與反向流程拆解法

我們專門針對這個旅程來找碴，就能發現一堆隱藏的魔鬼：

• 反向路徑：
  • 客戶的認證系統掛了怎麼辦？
  • 網路不穩，重新導向的過程中失敗了怎麼辦？
  • 使用者在客戶系統中，不小心按了「拒絕授權」怎麼辦？
  • 客戶傳回來的資料不完整，導致我們系統無法建立帳號怎麼辦？

第三刀：角色權限拆解法

我們用「權限矩陣圖」來思考 SSO 整合後的角色，立刻就能發現隱藏的工作：

透過整理這個矩陣圖，就可以先發現了幾個需要討論的關鍵問題：

• 當企業使用者登入時，我們系統如何辨識他們屬於哪個角色？
• 我方現有的客服人員權限與客戶的一般員工權限無法匹配，這需要開發額外的權限控制邏輯。
• 客戶系統管理員可以修改我們系統的權限，這會造成安全隱憂嗎？

第四刀：跨功能依賴拆解法

經過徹底的功能解剖後，我們還需要思考可能涉及的跨功能合作。與其他部門的協調往往是被低估的時間成本：

• 客戶的 IT 部門： 這是最重要的外部依賴！我們需要他們提供技術文件、設定環境、進行測試。
• 我們公司的資安部： 需要他們審核整個整合過程，是否符合公司的資安規範。
• 我們公司的法務部： 需要他們確認，與客戶交換員工資料，是否符合 GDPR 或其他隱私法規。

經過這四刀手術，那個原本看似一週就能搞定的 SSO 整合，已經被我們成功分解成一張包含數十個具體任務、涉及多方溝通協調的細節任務。此刻，你和你的團隊才能真正地、有根據地，去評估每一項任務所需的時間，最終匯總出一個遠比一週更可靠、也更能保護團隊的專案時程。

B 計畫：「現場應對」與「後續處置」

好，我們來談談那個最讓人胃痛的「但是」。

雖然「處方籤」教了我們如何摸清事實的全貌，但就像開頭的情境，我們最常遇到的，就是在高壓的會議中，就被當場要求給出時程。在這種情況下，就算是最有經驗的 PM，也很難在沒有跟技術團隊討論的情況下，輕易許下諾言。

那麼這份 B 計畫包含兩個部分：如何在被突襲的當下，優雅地拆招，以及如果拆招失敗，你還是被迫當場答應時，該如何自救。

第一部分：當下的「對話急救術」

回到開頭那個場景，當 CEO 問你「一週能不能搞定？」時，你該怎麼回覆，才能既不草率承諾，又不掃大家的興？這邊為你獻上即刻救援的「對話三部曲」 😆

1. 肯定與認同
   • 「老闆，完全同意！為了這個指標性客戶，展現我們的誠意與執行力絕對是第一優先！」
   • 潛台詞： 我跟你站在同一陣線，我理解你的目標。
2. 轉化為專業問題
   • 「為了確保我們給客戶的『第一印象』是完美的，而不是一個有 bug 的半成品，我需要和技術主管花十分鐘，快速對焦一下 SSO 整合的技術細節。」
   • 潛台詞： 我不是在質疑你，我是在用我的專業，來確保你的目標能被完美達成。
3. 提出具體承諾
   • 「請給我一點時間，我承諾在明天早上十點前，帶著一份更清晰的評估和行動方案，來跟您報告。」
   • 潛台詞： 我沒有說「不」，我只是要求一點點專業的反應時間，而且我給出了一個具體的下一步承諾。

第二部分：當你還是被迫當場答應時

如果，你用盡了上述的溝通技巧，老闆依然拍著桌子說：「我不管！我就是要在一週內看到東西！這是命令！」

此刻你的胃可能已經直接攪成一團了，但請記住，恐慌是你的敵人，而行動是你唯一的盟友!!!你的目標不再是「如何延後回覆」，反而是「如何重新定義『完成』」。

1. 立刻找技術主管「懺悔」與「結盟」

   會議一結束，立刻帶著你的筆電，衝到技術主管身邊。你的開場白必須極度誠懇：

   • 「老大，剛才我腦衝了，在 CEO 面前就答應一週能完成。我知道這很不專業，完全是我的錯。當下壓力太大，我根本無法拒絕這樣的要求。現在，我真的需要你的專業協助，讓我們一起把這個災難的影響降到最低。」
   • 潛台詞： 我承認錯誤，我尊重你的專業，我們現在是同一艘船上的人 :D。

2. 定義「一週奇蹟」的最小範疇

   和技術主管一起，用最快的速度，定義出一個能在七天內完成，且「看起來」像那麼回事的最小可行性版本。

   • 目標： 這可能不是一個功能完整的產品，比如可能是一個高擬真度的原型或 POC。
   • 範例：
     • 一個有漂亮 UI 的登入按鈕。
     • 點擊後，能跳轉到一個假的客戶登入頁面。
     • 輸入任何帳號密碼，都能成功登入，並看到一個靜態的產品主頁。
     • 最重要的一點： 和技術主管一起估算出，完成這個「奇蹟」需要多少人力。

3. 帶著「解決方案」，主動出擊

   不要等到 CEO 來問你進度。在第二天早上，主動敲開他的門。

   • 重申承諾，展現積極：
     「老闆，關於昨天提到的 SSO 專案，我昨晚和技術主管深入討論，我們非常有信心，能在一週內，給客戶一個印象深刻的 Demo！」
   • 重新定義「完成」，管理期望：
     「為了能在一週內達到這個目標，我們將會先完成一個『視覺與流程的驗證版本』，讓客戶能實際感受到登入的流暢體驗。而後續完整的後端串接與資安設定，我們也同步規劃了一份更詳細的時程，預計需要 X 週。」
   • 提出資源請求，展現專業：
     「為了確保下週的 Demo 能順利完成，我需要 [某位資深工程師] 在本週投入 100% 的時間，並暫緩他手上的 B 專案。這部分需要您的支持。」

你沒有說臣妾做不到，而是說「我做得到，並且『它』的樣貌是這樣，還有需要這些資源。」

最後的醫囑

所以，下次當你聽到「這個應該很簡單吧？」這句低語時，請在心中亮起紅色警報。

你的價值，不在於能多快給出一個虛假的樂觀時程，而在於你有多大的勇氣與專業能帶領團隊，一起潛入水面之下，看清那座冰山的全貌。把所有看不見的細節都攤在陽光下，雖然在一開始會帶來痛苦的爭論，卻是唯一能避免專案在未來撞上冰山、沉船的根本療法。

剛當 PM 的我：登入註冊是能有多難？不就是最簡單基礎的功能嗎？
事實上的登入註冊：